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ABSTRACT 


Our  goal  is  to  develop  techniques  for  abstracting  a  given  set  of 
programs  into  a  program  schema  and  for  instantiating  a  given  schema  to  satisfy 
concrete  specifications.  Abstraction  and  instantiation  are  two  important 
phases  in  software  development  that  allow  programmers  to  apply  knowledge 
learned  in  the  solution  of  past  problems  when  faced  with  a  new  situation.  For 
example,  from  two  programs  using  the  binary-search  method,  one  to  compute  quo- 
tients and  another  to  compute  cube-roots,  an  abstract  schema  can  be  derived 
that  embodies  the  shared  method  and  that  can  be  instantiated  to  solve  similar 
new  problems. 

We  suggest  the  formulation  of  analogies  as  a  basic  tool  in  program 
abstraction.  An  analogy  is  first  sought  between  the  specifications  of  the 
given  programs;  this  yields  an  abstract  specification  that  may  be  instantiated 
to  any  of  the  given  concrete  specifications.  The  analogy  is  then  used  as  a 
basis  for  transforming  the  existing  programs  into  an  abstract  schema  that 
represents  the  embedded  technique,  with  the  invariant  assertions  and  correct- 
ness proofs  of  the  given  programs  helping  to  verify  and  complete  the  analogy. 
A  given  concrete  specification  of  a  new  problem  may  then  be  compared  with  the 
abstract  specifications  of  the  schema  to  suggest  an  instantiation  of  the  sche- 
ma that  yields  a  correct  program.  These  methods  appear  to  be  amenable  to  im- 
plementation. 

A  collection  of  program  schemata  is  included  in  an  appendix. 
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I.  INTRODUCTION 

Chaque  verite  que  je  trouvais  etant  une  regie  qui  me  servait  apres  a 
en  trouver  d'autres,  non  seulement  je  vins  a  bout  plusieurs  que 
j'avais  jugees  autrefois  tres  difficiles,  mais  il  me  sembla  aussi, 
vers  la  fin,  que  je  pouvais  determiner,  en  celles  meme  que 
j'ignorais,  par  quels  moyens,  et  jusques  ou,  il  etait  possible  de 
les  resoudre. 

-  Rene  Descartes,  Discours  de  la  Methode 

When  confronted  with  a  task,  one  often  perceives  some  measure  of 
resemblance  between  the  given  task  and  a  previously  accomplished  one.  In  such 
a  case,  rather  than  "reinvent  the  wheel,"  one  is  likely  to  conserve  effort  by 
adapting  the  known  solution  of  the  old  problem  to  the  problem  now  at  hand. 
After  having  solved  several  similar  problems,  one  might  come  to  formulate  a 
general  paradigm  for  solving  such  problems  by  highlighting  the  shared  aspects 
of  the  individual  instances  and  supressing  their  inconsequential  or  idiosyn- 
cratic particulars.  The  process  of  formulating  a  general  scheme  from  concrete 
instances  is  termed  abstraction;  that  of  applying  an  abstract  scheme  to  a  par- 
ticular problem  is  termed  instantiation. 

Abstraction  and  instantiation  are  two  phases  in  the  evolutionary 
cycle  of  many  typical  programs,  a  cycle  that,  in  addition,  often  includes  the 
debugging  of  early  versions,  modifications  to  meet  amended  specifications,  and 
extensions  for  expanded  capabilities.  The  more  experience  a  programmer  has 
had,  the  more  programming  methods  he  is  likely  to  have  assimilated,  and  the 
more  judiciously  he  can  apply  them  to  new  problems.  After  having  written 
several  similar  programs,  a  programmer  is  apt  to  formulate  for  himself  —  and 
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perhaps  for  others  as  well  —  an  abstract  notion  of  the  underlying  principle 
and  reuse  it  in  solving  related  problems.  Program  schemata  are  a  convenient 
form  for  remembering  such  programming  knowledge.  A  schema  may  embody  basic 
programming  techniques  or  specialized  strategies  for  solving  some  class  of 
problems;  its  input-output  specifications  are  stated  in  terms  of  abstract 
predicate,  function,  and  constant  symbols. 

Our  goal  is  to  formalize  this  aspect  of  programming  by  developing 
automatable  techniques  for  abstracting  a  given  set  of  concrete  programs  into  a 
program  schema  and  for  instantiating  a  schema  to  satisfy  a  given  concrete 
specification.  The  programs  are  assumed  to  be  annotated  with  an  output 
specification  (stating  the  desired  relationship  between  the  input  and  output 
variables  upon  termination  of  the  program),  an  input  specification  (defining 
the  set  of  legal  inputs  on  which  the  program  is  intended  to  operate) ,  and 
invariant  assertions  (relations  that  are  known  to  always  hold  at  specific 
points  in  the  program  for  the  current  values  of  variables)  demonstrating  its 
correctness. 

To  date  there  has  been  a  limited  amount  of  research  on  program 
abstraction.  The  STRIPS  system  (Fikes,  Hart,  and  Nilsson  [1972])  generalized 
the  loop-free  robot  plans  that  it  generated;  the  HACKER  system  (Sussman 
[1975])  "8ubroutinized"  and  generalized  the  "blocks-world"  plans  it  syn- 
thesized, executing  the  plan  to  determine  which  program  constants  could  be 
abstracted.  Dershowitz  and  Manna  [1975]  suggest  using  the  proof  of  correct- 
ness of  a  program  to  guide  the  abstraction  process. 
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A  number  of  researchers  have  dealt  with  the  use  of  program  schemata. 
Dijkstra  [1972]  maintains  that  theorems  about  schemata  are  unconsciously 
invoked  by  the  programmer.  Wirth  [1975]  illustrates  the  use  of  basic  schemata 
in  the  systematic  development  of  programs.  Gerhart  [1975],  Gerhart  and 
Yelowitz  [1976],  and  Yelowitz  and  Duncan  [1977]  have  all  advocated  and  illus- 
trated the  use  of  schemata  as  a  powerful  programming  tool.  Other  examples  of 
the  use  of  abstract  algorithms  as  first  steps  in  the  development  of  programs 
are  Darlington  [1978],  Deussen  [1979],  Duncan  and  Yelowitz  [1979],  and  Lee, 
deRoever,  and  Gerhart  [1979].  In  a  similar  vein,  Plaisted  [1980]  demonstrates 
how  abstractions  may  be  used,  with  great  effectivity,  for  theorem  proving.  An 
approach  to  the  specification  and  verification  of  program  schemata  is  given  in 
Misra  [1978]. 

We  suggest  the  formulation  of  analogies  as  a  basic  tool  in  program 
abstraction.  First,  an  analogy  is  sought  between  the  output  specifications  of 
the  given  programs.  This  yields  an  abstract  output  specification  that  may  be 
instantiated  to  any  of  the  given  concrete  specifications.  The  analogy  is  then 
used  as  a  basis  for  transforming  the  existing  programs  into  an  abstract  schema 
that  represents  the  embedded  technique.  The  invariant  assertions  and  correct- 
ness proofs  of  the  given  programs  are  used  to  extend  and  complete  the  analogy. 

A  schema,  derived  in  this  manner,  is  usually  not  applicable  to  all 
possible  instantiations  of  its  specifications.  In  that  case,  the  schema  Is 
accompanied  by  an  input  specification  containing  conditions  that  must  be 
satisfied  by  the  instantiation  in  order  to  guarantee  correctness.   These 
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preconditions  may  be  derived  from  the  verification  conditions  or  correctness 
proof  of  the  schema.  The  abstract  specifications  of  the  schema  may  then  be 
compared  with  a  given  concrete  specification  of  a  new  problem.  By  formulating 
an  analogy  between  the  two  specifications,  an  instantiation  is  found  that 
yields  a  concrete  program  when  applied  to  the  schema.  If  the  instantiation 
satisfies  the  preconditions,  then  the  correctness  of  the  new  program  is 
guaranteed.  If  not,  analysis  of  the  unsatisfied  conditions  may  suggest  modif- 
ications that  will  lead  to  a  correct  program. 

The  importance  of  analogical  reasoning  has  been  stressed  by  many, 
from  Descartes  to  Polya.  For  a  review  of  psychological  theories  of  analogical 
reasoning  see  Sternberg  [1977].  The  use  of  analogy  in  automated  problem  solv- 
ing in  general,  and  theorem  proving  in  particular,  was  proposed  by  Kling 
[1971].  Other  works  employing  analogy  as  an  implement  in  problem  solving 
include  Brown  [1976],  Chen  and  Findler  [1976],  McDermott  [1979],  and  Winston 
[1980].  Using  analogies  to  guide  the  modification  of  programs  has  been  inves- 
tigated by  Manna  and  Waldinger  [1975],  Dershowitz  and  Manna  [1977],  Ulrich  and 
Moll  [1977],  and  Dershowitz  [1978]. 

In  the  next  section  we  present  several  illustrations  of  our 
approach.  Some  schemata  that  have  appeared  in  the  literature  are  collected  In 
the  Appendix. 
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II.  EXAMPLES 

This  section  contains  three  detailed  examples  of  program  abstraction 
and  instantiation.  Each  example  begins  with  two  concrete  programs,  annotated 
with  their  specifications  and  invariant  assertions.  Then,  the  programs  are 
abstracted  to  obtain  a  more  general  program  schema.  Finally,  each  schema  is 
instantiated  to  satisfy  a  third  concrete  specification. 


Example  1:  Extremum  Schema 


Consider  the  following  program: 

P i :    begin 

comment     minimum  value  program 

assert   nelN 

(z,i)    :=   (A[0],0) 

loop     assert   z<A[0:i],    ielN 

until   i=»n 

1    :=   i+1 

if  A[i]<z  then  z  :=  A[l]  fi 

repeat 
assert  z<A[0:n] 
end, 

where  U  is  the  set  of  nonnegative  integers  and  for  predicate  a  the  construct 
a[u:w]  is  shorthand  for  (VveZ)(u<v<w)a(v) ,  i.e.  a  holds  for  all  integers 
between  u  and  w.  The  output  specification  of  this  program  is  given  in  the 
statement 
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assert  z<A[0:n]; 

it  states  that  upon  termination  of  program  P^  the  value  of  z  is  less  than  or 
equal  to  any  value  appearing  in  the  array  segment  A[0:n].  The  input  specifi- 
cation of  this  program  is  given  in  the  initial  assertion 

assert  nelN; 

it  states  that  the  value  of  the  input  variable  n  must  be  a  nonnegative 
Integer.   The  statement 

assert  z<A[0:i],  ieIN 

at  the  head  of  the  loop  contains  two  relations  —  invariant  assertions  —  that 
hold  for  the  current  values  of  the  variables  i  and  z  each  time  control  reaches 
that  point  in  the  program.  The  invariants  are  first  made  true  by  the  multiple 
assignment 

(z,i)  :=  (A[0],0). 

The  two  loop-body  statements 

i  :=  i+1 

if  A[i]<z  then  z  :=  A[i]  fi 

maintain  the  truth  of  the  invariants,  i.e.  assuming  that  the  invariants  are 
true  before  the  statements  are  executed,  the  invariants  remain  true  after- 
wards.  The  loop  body  is  repeated  (zero  or  more  times)  until  the  test 

until  i-n 

becomes  true;  at  that  point  the  loop  is  left,  and  the  output  specification 
holds. 

The  second  program  is 
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Qi:  begin 

comment  maximum  position  program 
assert  k,JteZ,  k<l 

(P,j)  :-  (*,*) 

loop     assert   B[p] >B [ j : X] ,    p.jeZ 
while    j>k 

j    :-   j-l 

if  ~l(B[p]>B[j])  then  p  :=  j  fi 

repeat 
assert  B[p]>B[k:£] 
end, 

where  Z  is  the  set  of  all  integers.   This  program  finds  the  position  p  of  a 
maximal  element  in  the  array  segment  B[k:A];  its  output  specification  is 

assert  B[p]>B[k:A] . 

Its  input  specification 

assert  k,£eZ,  k<£ 

requires  that  the  two  input  variables  k  and  A  be  integers  and  that  k  not  be 
greater  than  A  so  that  the  array  segment  B[k:£]  is  nonempty. 

Both  programs  perform  a  linear  search  for  an  extremum  in  an  array 
segment.  Our  task  is  to  extract  an  abstract  version  of  these  two  programs 
that  captures  the  essence  of  the  technique  used,  but  that  is  not  specific  to 
either  problem.  The  resultant  schema  can  then  be  used  as  a  model  of  linear 
search  for  the  solution  of  future  problems. 

The  first  step  in  abstracting  these  two  programs  is  to  find  an  anal- 
ogy between  their  respective  output  specifications,  z<A[0:n]  and  B[p]>B [k: I] . 
The  obvious  analogy  is  that  where  the  specification  of  Pj  has  0,  n,  <,  A,  and 
z,  the  specification  of  Qi  has  k,  I,  >,  B,  and  B[p],  respectively.  This  anal- 
ogy is  denoted  by 
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0  «-►  k 

n  <— ►  I 

<      +-►  > 

A  -*-♦  B 
z  *-*-   B[p]  . 

Now  abstract  entities  may  be  substituted  for  analogous  parts.  Each  pair  in 
the  analogy  is  replaced  by  an  abstract  variable  of  the  same  kind:  the  scalar 
constant  0  in  P^  and  the  corresponding  scalar  input  variable  k  in  Q^  may  be 
replaced  by  an  abstract  input  variable  <;  the  corresponding  input  variables  n 
and  X  may  be  replaced  by  \;  the  predicate  constants  <  and  >  are  abstracted  to 
a  predicate  variable  a;  the  input  arrays  A  and  B  generalize  to  A;  and  the 
variable  z  and  variable  expression  B[p]  generalize  to  a  program  variable  \l. 
(We  shall  use  Greek  letters  to  distinguish  all  abstract  entities.) 

Applying  the  transformations 

0  -►  K 

n  -+  X 

<  -»•  a 

A  -*>  A 

z  -*  u 

to  the  output  specification  of  Pj  yields  the  abstract  specification 

assert  <x(h,A[k:\]  ). 

Such  a  set  of  transformations  is  called  an  abstraction  mapping.  The  abstrac- 
tion mapping 
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a  — ►  k 
I  -*■  \ 
>  -*  a 
B  -*  A 
p  -►  pos(A,u), 

where  pos(A,|i)  is  a  function  that  returns  the  position  of  some  occurrence  of  [i 
in  the  array  A,  yields 

assert  a(A[pos( A,u) ] ,A[<:\] ) 

when  applied  to  the  output  specification  of  Qi .   This  simplifies  to  the  same 
abstract  specification 

assert  a(u,A[<:\]), 

since  by  definition  A[pos(A,u) ]=u. 

In  general  there  are  several  possible  ways  in  which  an  expression  of 
the  form  f(q,r)  can  be  compared  with  an  expression  h.  If  h  is  of  the  form 
g(s,t),  then  the  imitating  mapping  f-*g,  q— »-s,  and  r— *-t  suggests  itself.  If  f 
has  an  inverse  f  in  its  first  argument,  i.e.  f(f  (u,v),v)=u,  then  the  invert- 
ing mapping  q— »-f  (h,r)  would  work.  If  f  has  an  identity  element  f  in  its 
first  argument,  i.e.  f(f  ,v)=v,  then  the  collapsing  mapping  q— »-f  and  r— ►h  is 
possible.  Another  possibility  is  the  projecting  mapping  f—*%  and  r— ►h,  where 
%  projects  its  first  argument,  i.e.  ti(u,v)sbu.  (Similar  mappings  work  for 
other  than  the  first  argument.)  For  a  discussion  of  a  second-order  pattern- 
matcher  that  uses  imitating  and  projecting  mappings  and  its  application  to 
program  manipulation  see  Huet  and  Lang  [1978]. 

In  our  example,  to  compare  z<A[0:n]  with  B[p]>B[k: I] ,  the  imitating 
mapping  O*— »-a,  n«-+-b,  and  z<A[u]«— *[p]  >B[u]  is  first  used  (eliminating  the 
quantifiers  [0:n]  and  [k:A]).  To  compare  z<A[u]  with  B[p]>B[u],  another  imi- 
tating mapping,  viz.  <■*—►>,  z«— >B[p],  and  A[u]+->B[u],  is  used.  An  inverting 
mapping  is  needed,  for  example,  to  abstract  B[p]  into  \i  for  Qj :  since  B  is 
abstracted  into  A,  we  need  to  map  A[p]  into  [i;    since  pos  is  an  inverse  of  the 


-  11  - 

array  access  function,  we  get  p— ►pos(A,u) .  An  example  of  a  projecting  mapping 
would  be  A— *it  and  p— *-[i. 

The  next  step  in  abstracting  Pi  and  Qj  is  to  apply  the  mappings  to 
the  corresponding  programs.  Applying  the  first  set  of  transformations  to  P^ 
yields 

S i :  begin 

comment   tentative  extremum  schema 

suggest  XeIN 

(u,i)  :=  (A[<],<) 

loop     suggest   a(n,A[<:i]),    ieIN 

until   i=\ 

i    :=   i+1 

if  A[i]<u  then  u  :=  A[i]  fi 

repeat 
suggest  a(u,A[<:\] ) 
end. 

Had  all  the  transformations  been  of  variables,  as  are  n— ►X,  A— »-A,  and  z— *\i, 
then  applying  the  transformations  to  all  occurrences  of  those  variables  in  the 
annotated  program  would  of  necessity  have  resulted  in  a  correct  schema.  But 
since  the  abstraction  mapping  involves  the  transformation  of  constant  symbols 
as  well,  viz.  0  and  <,  this  schema  is  not  necessarily  correct.  We  have  there- 
fore replaced  the  assertions  with  "suggestions"  containing  those  relations 
that  we  would  like  to  be  invariants. 

In  general,  a  global  transformation,  where  an  input  variable  (e.g.  n 
or  A)  is  systematically  replaced  —  in  the  assertions  as  well  as  in  the  code 
—  by  some  function  of  only  input  variables,  will  always  yield  a  program  (or 
program  schema)  that  satisfies  the  transformed  input-output  specifications. 
Similarly,  systematically  replacing  a  program  (or  output)  variable  (e.g.  z)  by 
a  function  of  (input  or  program)  variables  preserves  correctness  with  respect 
to  the  specifications.  However,  global  transformations  of  constants  (e.g.  0 
and  <)  might  be  overzealous  or  Incomplete,  and  they  are  not  guaranteed  to 
result  In  a  program  satisfying  the  specifications.   That  is  because  the 
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correctness  of  the  original  program  may  have  depended  on  properties  of  these 
constants  that  do  not  hold  for  their  transformed  counterparts.  There  could, 
for  example,  be  unrelated  occurrences  of  0  in  Pj ,  say  for  the  purpose  of 
illustration  that  the  exit  test  were  i+0=X  or  that  there  was  an  additional 
loop-body  assignment  i:=i+0,  in  which  cases  the  transformation  0— *■<  would  be 
inappropriate.  Or  the  predicate  symbol  <  might  not  appear  explicitly  in  the 
program  code  at  all,  as  indeed  it  does  not,  in  which  case  the  transformation 
<— *-a   would  be  insufficient. 

One  must  therefore  examine  the  schema's  verification  conditions  to 
determine  under  what  assumptions  the  suggestions  may  in  fact  be  invariants. 
First,  consider  the  loop-exit  path 

suggest  a(u,A[<:i]),  ielN 

assert  i=\ 

suggest  a(u,A[<:\]). 

(The  first  suggestion  is  the  transformed  loop  invariant  that  we  are  assuming 
was  true  when  control  was  last  at  the  head  of  the  loop;  the  second  statement 
asserts  that  the  exit  test  was  true  at  that  time  and  therefore  the  loop  was 
exited;  the  final  suggestion  contains  the  desired  output  relations  with 
respect  to  which  we  are  trying  to  prove  this  schema  correct.)  For  this  path  to 
be  correct,  the  loop  invariants  in  the  first  suggestion,  together  with  the 
exit  test  of  the  assertion,  must  imply  that  the  desired  output  relation  in  the 
second  suggestion  holds,  i.e.  the  verification  condition  for  the  exit  path  is 

a(u,A[<:i])  A  ielN  A  i=X  D  a(u,A[ic:X]  ). 

Indeed,  if  a(u,A[<:i])  holds  and  i=\,  then  a(u,A[<:\])  holds  as  well.  Thus, 
if  we  can  establish  that  a(|i,A[<:i] )  and  IelN  are  loop  invariants,  then  the 
schema  is  correct. 

Next,  we  consider  the  initialization  path 
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suggest  XeIN 

(|i,I)    :=    (A[<],<) 

suggest  a(u,A[tc:i]  ),  ielN. 

Its  verification  condition  is 

\e!N  3  <x(A[k],A[k:k])  A  <elN. 

(This  condition  Is  obtained  from  the  path  by  substituting  the  new  values  A[<] 
and  <  assigned  to  the  variables  n  and  I,  respectively,  for  occurrences  of  the 
variables  in  the  suggestion  following  the  assignment.)  The  subterm  A[<:<]  sim- 
plifies to  A[<].  For  cosmetic  purposes,  we  shall  replace  the  expression  A[<] 
in  oc(A[k]  ,A[<] )  by  the  universally  quantified  u  and  just  write  a(u,u),  i.e.  a 
must  be  reflexive.   Since  there  is  no  way  of  showing 

or 

ct(u,u) 

to  hold,  they  are  both  left  as  preconditions  for  the  schema  to  be  correct. 

The  loop-body  path  verification  condition  is  composed  of  two  cases, 
one  for  each  possible  outcome  of  the  conditional  test.  In  the  case  when  the 
test  fails,  the  then-branch  is  skipped: 

suggest  a(u,A[<:i]),  iclN 

assert  ~ |(i=*\ ) 

i  :-  1+1 

assert  ~l(A[i]<u) 

suggest  a(u,A[<:i]),  ielN. 

To  verify  this  path  we  must  show  that  the  loop  invariants  continue  to  hold  if 
the  exit  test  is  false,  i  is  incremented,  and  the  conditional  test  is  false. 
The  corresponding  verification  condition  is 
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a(n,A[<:i])  A  lelN  A  l(i=\)  A  ~l(A[i+l]<u)  D  a(u,A[«:i+l]  )  A  i+leU. 

Clearly,  if  IelN  before  executing  i:-i+l,  then  ielN  after,  i.e.  ielN 
implies  i+lelN.  We  must  also  show  a([i,A[<:i+l] ).  But  it  is  already  assumed 
that  a(u,A[ic:i]  );  all  that  remains  to  show  is  a(u,A[i+l]).  The  only  possibly 
relevant  assumption  (relating  u  and  A[i+1])  is  ~~|(A[i+l]  <u),  i.e.  ~|(A[i+l]<u) 
should  imply  a(u,A[i+l] ).  Of  course,  since  a  is  an  abstract  predicate,  there 
is  no  reason  for  that  to  be  the  case.  Accordingly,  we  look  for  an  abstraction 
mapping  that  will  unify  the  two  relations: 

~l(A[i+l]<u)  -  <x(u,A[i+l]). 

Inverting  gives 

A[i+1]<^  -»  "|a(u,A[i+l]); 

imitating  leaves 

u<v  -*  ~1a(v,u) . 


Applying  this  additional  transformation  to  (the  loop  body  of)  the 
schema,  we  get  the  conditional  statement 

if  ~|a(u,A[i])  then  \x   :=  A[i]  fi. 

Now  the  verification  condition  for  the  case  when  the  test  is  false  carries 
through,  and  it  remains  to  verify  the  other  case  when  ~~ |a(|i,A[i]  )  is  true: 
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suggest  a(u,A[ic:i]  ),  ielN 

assert  ~|(i=X) 

i  :=  i+1 

assert   |cx  (|i ,  A  [  i  ]  ) 

u  :=  A[i] 

suggest  ct(u,A[ic:i]  ),  ielN. 

The  verification  condition  for  this  case  is 

a(u,A[i<:i])  A  ielN  A  ~|(i=X)  A  ~|a(ji,A[i+l]  )  D   a(A[i+l]  ,A[tc:i+l]  )  A  i+lelN. 

Again,  the  invariant  ielN  is  clearly  maintained,  and  since  we  are  already 
assuming  that  a  is  reflexive,  i.e.  a(A[i+l] ,A[i+l] ) ,  we  need  only  ascertain 
a(A[i+l]  ,A[<:i]  ).  Since  there  is  no  way  to  prove  this  to  hold  for  all  a,  it 
is  left  as  a  precondition: 

a(n,A[<:i])  A  ielN  A  ~l(i=X)  A  ~la(u,A[i+l] )  Z>   a(A[i+l]  ,A[<:i]  ) 

For  convenience,  we  shall  replace  this  with  (the  more  general  condition) 

a(w,u)  A  ~|a(w,v)  3  a(v,u). 

Finally,  we  consider  the  verification  condition  for  termination: 

\e!N  D  GuelN)K+u=\ 

(i.e.  the  exit  test  i=*\  will  eventually  hold  for  some  value  k+u  of  i) .  Since 
K,\elN  is  assumed  to  hold  (XeIN  appears  in  the  suggested  input  specification 
and  keIN  is  a  precondition),  this  termination  condition  is  equivalent  to 

<<X. 

This  too  is  left  as  a  precondition. 
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Applying  the  complete  abstraction  mapping 

0  -►  K 
n  -*■  \ 

<  -*  a 

A  -►  A 

z  -*  [i 

u<v  — ►  ~|a(v,u) 

to  program  P^ ,  our  final  version  of  the  schema  is 

S} :  begin 

comment  extremum  schema 

assert  a(u,u),   a(w,u)  A~la(w,v)2)a(v»u)  >   <AelN,    <<K 

(u,i)    :=    (A[k],k) 

loop     assert  a(n,A[<: i] ) ,    ielN 

until  i-X 

i    :=   i+1 

if  la(u,A[i])  then  \x   :=  A[i]  fi 

repeat 
assert  a(  \i ,  A  [  < :  \  ]  ) 
end. 

Now  that  we  have  verified  the  conditions  for  each  of  the  paths  in  the  program, 
the  suggestions  have  been  replaced  by  assertions.  The  preconditions  are  given 
in  the  input  assertion;  any  instantiation  that  satisfies  them  is  guaranteed  to 
yield  a  correct  program.  Obviously,  the  predicate  a  that  appears  in  the 
schema  should  be  instantiated  to  a  primitive  predicate  available  in  the  target 
language;  otherwise  it  must  be  replaced  by  something  equivalent  for  the  schema 
to  yield  an  executable  program.  Likewise,  the  constants  A,  tc,  and  X  must  be 
replaced  with  primitives. 

Recall  that  the  given  output  specification  of  program  ?i   was 
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assert  z<A[0:n] . 

Actually,  a  more  realistic  specification  for  a  search  for  a  minimum  would  have 
included  the  relation  zeA[0:n],  i.e.  not  only  should  z  be  no  larger  than  any 
element  of  A[0:n],  but  it  should  be  one  of  those  elements.  If  we  apply  the 
abstraction  mapping  that  we  have  found  to  this  additional  specification  as 
well,  we  get  the  abstract  relation  neA[ic:\]  which  indeed  may  be  shown  to  hold 
for  the  schema  we  have  derived.  We  also  note  that  had  we  applied  the 
corresponding  abstraction  mapping  to  Qi  instead  of  to  P],  a  somewhat  dif- 
ferent, but  equally  valid,  schema  would  have  resulted. 

The  schema  S^  can  be  instantiated  to  find  the  position  or  value  \i  of 
either  the  minimum  or  maximum  of  any  function  A  over  some  domain  of  nonnega- 
tive  integers  in  the  range  [<:\].  For  instance,  say  we  want  to  find  the  posi- 
tion m  of  the  minimum  of  some  function  f  for  the  odd  integers  in  the  interval 
[1:100].   Comparing  this  goal 

achieve  (Vue[l  :100]  )(odd(u)3f  (m)<f  (u)  ) 

with  the  abstract  output  specification  of  the  schema 

assert  a(  \i ,  A  [  < :  X  ]  )  , 

suggests  first  applying  the  imitating  mappings  <— »-l,  \-»-100,  and 
a(u,A[u]  )— »-odd(u)3f (n0*f  (u)  •  The  last  of  these  mappings  can  be  accomplished 
by  the  projecting  and  imitating  mappings  A— Ht,  a(v,u)— ►oddCu)^^  (v)*f  (u) »  an<^ 
H— *-m,  where  n   is  the  identity  function. 

Applying  the  instantiation  mapping 
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K    -*  1 

\   -►  100 

A  -*>  it 

a(v,u)  -►  odd(u)3f(v)<f(u) 

p,  — ►  m 


to  the  preconditions 


a(u,u) 
a(w,u)  A  ~|a(w,v)  Z)   <*(v,u) 


yields 


l,100elN 

odd(u)  Z>   f(u)<f(u) 

|"odd(u)Df(w)<f(u)l  A  ~irodd(v)I)f(w)<f(v)l  3  fodd(u)I)f(v)<f (u)l 

K100. 

The  first  and  last  conditions  are  obviously  true;  the  second  holds  since  <  is 
reflexive;  the  third  follows  from  transitivity.  Applying  the  above  instantia- 
tion mapping  to  the  schema  yields 

Rl :  begin 

comment   function  minimum  program 

(m,i)  :-  (1,1) 

loop  assert  (Vue[l:  i]  )(odd(u)I)f  (m)<f  (u)  ),  ielN 

until  i=100 

i  :=  i+1 

if  odd(i)Af(i)<f(m)  then  m  :=  i  fi 

repeat 
assert  ( Vue[l: 100] )(odd(u)I)f (m)<f (u)) 
end. 

(The   transformed   conditional   test   ~|(odd(i)3f  (m)<f  (i) )   simplifies   to 
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odd(i)Af(i)<f(m).) 

Since  the  preconditions  were  satisfied  by  the  instantiation,  this 
program  is  guaranteed  to  be  correct.  Further  improvements  to  the  instantiated 
program  can  be  made  (e.g.  incrementing  i  by  two)  by  a  straightforward  series 
of  program  transformations  such  as  those  catalogued  in  Standish,  et  al. 
[1976]. 

Example  2:    Binary-Search  S chema 

The  following  two  programs  both  use  the  binary-search  technique. 
The  first  program 

P2 :  begin 

comment   real  division  program 

assert  0<c<d,  e>0 

(q,y)  :-  (0,1) 

loop  assert  q<c/d,  c/d<q+y 

until  y<e 

y  :=  y/2 

if  d*(q+y)<c  then  q  :=  q+y  fi 
repeat 

assert  |q-c/d|<e 
end 

uses  that  technique  to  find  the  quotient  q  of  two  nonnegative  real  numbers  c 
and  d,  c<d,  within  a  given  positive  tolerance  e.   The  second  program 
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Q2:  begin 

comment  cube-root  program 
assert  x>l,  t>0 

(r,w)  :-  (l,x) 

„  1/3   1/3^ 
loop  assert  r<x   ,  x   <w 

while  w-r>t 


s  :=  (w+r)/2 

else  w  :=  s  fl 


3 
if   s  <x    then  r  :=  s 


repeat 

I   1 /3  i  , 
assert  | r-x   | <t 

end 

finds  the  cube  root  r  of  the  real  number  x,  x>l,  within  positive  tolerance  t. 

In  comparing  their  respective  output  specifications,  an  obvious 
analogy  is 

q  «— ►  r 
u/d  «-*  u 
c  •*-►  X 

e  «— >   t. 

If  we  apply  the  abstraction  mapping 


q  -  I 

u/d  -*■   <J)(u) 

c  -*>  p 

e  -►  e 


to  P2»  we  obtain  the  schema 
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S2 :  begin 

comment   tentative  binary-search  schema 

suggest  0<p<d,  e>0 

(F,y)  :=  (0,1) 

loop  suggest  !;<<(>( p),  4>(p)<£+y 

until  y<e 

y  :=  y/2 

if  dx(£+y)<p  then  I    :=  £4y  fi 

repeat 
suggest  |^-<j>(p)|<e 
end. 

As  In  the  previous  example,  we  have  replaced  the  assertions  with  suggestions 
to  indicate  that  this  schema  may  be  incorrect. 

This  time,  rather  than  look  just  at  verification  conditions,  we  ima- 
gine that  the  programmer  has  supplied  detailed  comments  on  the  reasoning  he 
employed  in  constructing  P2  and  O^.  Such  additional  information  may  help  in 
extending  the  analogy  between  the  programs  and  arriving  at  a  correct  schema. 
It  may  also  allow  the  localization  of  transformations  to  relevant  occurrences 
of  symbols  and  will  help  avoid  unnecessarily  strict  preconditions. 

The  output  specification  of  P2  was 

assert  |q-c/d|<e. 

The  programmer  achieved  the  desired  relation  |q-c/d|<e  by  decomposing  it  into 
the  three  conjunctive  subgoals  given  in  the 

purpose  q<c/d,  c/d<q+y,  y<e. 

(This  is  just  a  comment  left  by  the  programmer  listing  the  relations  he  meant 

his  code  to  achieve.)  The  last  conjunct  became  the  exit  test  of  the  loop  and 

the  other  two  became  loop  invariants.   Abstracting  these  subgoals,  by  applying 
the  mapping,  gives 
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purpose  £<<J>(p),  <Kp)<S+y,  y<e» 

which  indeed  imply  (and  are  all  needed  to  imply)  the  desired  output  specifica- 
tion of  the  schema  |2;-<j>(p)  |<e. 


Similarly,  the  goal 


purpose  I r-x   | <t 


of  program  Q2  was  reduced  to  the  three  subgoals 

1/3   1/3 
purpose  r<x   ,  x   <w,  ~](w-r>t) . 

Applying  the  abstraction  mapping 

r  -*•  I 

u    ■*  <j>(u) 

x  -»■  p 

t  -*  e 

to  these  subgoals  yields 

purpose  Z<$( p),  <t>(p)<w,  ~|(w-£>e). 

This  is  not  however  identical  with  the  subgoals  for  P2;   to  make  them 
equivalent  requires  extending  the  analogy  with 

S+y  «— ►  w. 

If  we  let  ti  be  their  abstract  counterpart,  then 

y  -*  r\-Z 

must  be  added  to  the  abstraction  mapping  of  P2  and 
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w 


to  the  mapping  for  Q2 . 

There  are,  however,  problems  with  applying  the  transformation  y-*"n-£ 
to  the  statements  of  P2«  If  we  apply  it  in  a  straightforward  manner  to  the 
initialization  assignment  (E  ,y)  :  =  (0,1) ,  then  we  obtain  (F,,t)-?;):  =  (0,1) .  But 
the  assignment  n-£:=l  is  illegal,  as  an  expression  such  as  n-^  may  not  appear 
on  the  left-hand  side  of  an  assignment.  Nevertheless,  the  desired  effect  of 
making  the  difference  between  the  new  values  of  r\  and  E  equal  to  1  can  be 
achieved  by  the  legal  assignment  r|:=l+0,  since  0  is  the  new  value  of  £.  Simi- 
larly, the  transformed  loop-body  assignment  n-!;:  =(n-£)/2  is  illegal.  To  make 
it  legal,  the  £  must  be  transposed  to  the  right-hand  side;  the  resulant 
assignment  is  n:=(Ti+^)/2 . 

We  are  not  yet  finished,  however,  as  the  value  of  the  difference  Tp£ 
also  changes  whenever  £  is  assigned  to.  Accordingly,  we  must  look  at  the 
then-branch  assignment  £:=£+y,  or  rather  at  (5,y) :=(£+y ,y) ,  where  we  have 
explicitly  included  a  dummy  assignment  to  the  variable  y.  Transforming  this 
gives  (r, ,ti-C):  =  (^+ti-^,ti-^).  Thus,  £  should  get  the  value  n  and  n  should  get 
the  value  rr?  plus  the  new  value  of  £,  i.e.  the  old  value  of  n.  The  appropri- 
ate legal  assignment  is  accordingly  (£,n)  :  =  (Ti,2*n-£). 

At  this  stage,  the  abstracted  program  is 
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begin 

comment   tentative  binary-search  schema 
suggest  0<p<d,  £>0 
a,n)  :-  (0,1) 

loop  suggest  £<<t>(p),  <j>(p)<n 
until  TT^<e 

n  :=  (n+O/2 

if  d*n<p  then  (S,n)  :-  (n,2*T)-!;)  fi 

repeat 
suggest  | C— <p Cp >  I  <e 
end. 


The  initialization  of  the  division  program  was  correct  since  q=0  and 

y=l  imply  q<c/d<q+y;  the  correctness  of  the  initialization  of  the  cube-root 

1/3 
program  follows  from  the  fact  that  r=l  and  w=a  imply  r<a   <w.   This  suggests 

extending  the  analogy  with  0«-*l  and  1-*— ►a  and  extending  the  abstraction  map- 
pings with 

0  -►  o  <-  1 

1  -*  i  +—  x. 

These  transformations  need  only  be  applied  to  the  respective  initializations. 
The  resultant  abstract  condition  for  the  correctness  of  the  initialization  is 

o<<Kp)<i  • 

This  is  our  first  precondition;  it  replaces  the  abstracted  input  specification 
0<p<d. 

The  purpose  that  the  programmer  had  in  mind  for  the  loop  body  of  P2 
was 


purpose  q<c/d,  c/d<q+y,  0<y<y' , 
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where  y'  denotes  the  value  of  the  variable  y  when  control  was  last  at  the  head 
of  the  loop.  In  other  words,  the  loop  body  reachleves  the  invariants  while 
making  progress  towards  the  exit  test  by  decreasing  y  (some  minimal  amount  — 
to  ensure  termination).  Abstracting  this  goal,  or  the  corresponding  one  for 
Q2,  yields 

purpose  £<<K p),  <Kp)<n,  0<tp5<ti'-£'. 


To  achieve  the  last  conjunct  of  the  loop-body  goal,  the  division 
program  decreases  y.  Then,  to  achieve  the  remaining  two  conjuncts,  a  condi- 
tional statement  with  the 

purpose  q<c/d,  c/d<q+y 

(for  the  decreased  value  of  y)  is  introduced.   Since  only  the  value  of  y  has 

so  far  been  changed  by  the  loop  body,  q<c/d  still  holds,  but  c/d<q+y  might 

not.   The  program  determines  if  the  latter  still  holds  by  testing  the 

equivalent  condition  d*(q+y)<c   It  is  here,  however,  that  the  correctness  of 

the  schema  breaks  down:   the  transformed  test  d*n<p  does  not  determine  if  the 

3 
abstract  relation  <J> ( p ) <n  holds.   Similarly,   the  test  n  <p  obtained  by 

abstracting  Q2  does  not  test  for  <t>(p)<n. 

There  is,  nevertheless,  an  analogy  between  the  tests  in  P2  and  Q2. 

3 
where  the  former  has  the  function  d*u,  the  latter  has  u  .   Accordingly,  the 

analogy  between  P2  and  Q2  is  extended  with 

3 

d*u  — ►  4»(u)  ■*—   u  . 


Now,  for  the  conditional  statement  to  have  the  desired  effect,  we 
need  ~~I(<K(t)+0/2  )<p)  to  imply  $(p)<(TrHr,)/2 ,  or  more  generally 

~|((Ku)<v)  Z>   4>(v)<u. 

This  becomes  a  precondition.   We  must  also  determine  the  conditions  under 
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which  the  then-branch  of  the  conditional  is  correct.  That  case  was  correct  in 
the  division  program  because  d*(q+y/2)<c  implies  q+y/2<c/d  and  c/d<q+y  implies 
c/d<q+y/2+y/2.  For  the  abstracted  schema,  then,  we  need  <K(t)+£)/2)<p  to  imply 
(n+£)/2<<Kp)  and  <Kp)<T)  to  imply  <Kp)<2*(n+S)/2-£.  The  second  implication 
obviously  holds;  the  first  yields  the  precondition 

<l>(u)<v  D  u<<|>(v). 

Combined  with  the  previous  precondition,  we  have 

4»(u)<v  =  u<<|>(v) , 

which  holds,  in  particular,  if  <\>  is  the  inverse  of  a  monotonic  function  <f>, 
i.e.  if  <()((p(u))!»u  and  u<v=<t>(u)<<J>(v)  • 

Putting  everything  together,  the  complete  abstraction  mapping  for  P2 
is 

u/d  -»•  4>(u) 

c  -»•  p 

e  -*■   e 

dxu  -►  4>(u) 

y  -*>  rrl 

0  -+  o 

1  -►  1 

and  we  have  derived  the  schema 
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begin 

comment  binary-search  schema 
assert  (Ku)<v=u<<t>(v)  >  o<<t>(p)<i,  £>0 
(E,n)  :=  (0,1) 
loop  assert  £<<t>(p),  <t>(p)<ri 
until  tt£<£ 

n  :=  (n+C)/2 

if  <Kn)<p  then  (F,,n)  :=  (n,2*r,-5;)  fi 

repeat 
assert  |£-<J>(p)|<e 
end. 


This  schema  may  be  slightly  optimized  by  applying  the  correctness- 
preserving  global  transformation  n— ^-Hi.   The  schema 

S2 :  begin 

comment  binary-search  schema 
assert  <Ku)<v=u<<J>(v) »  0<4>(p)<i,  £>0 
(£>n)  :=  (o,\-o) 
loop  assert  £<<|>(p),  <Kp)<£+ri 

until  n<e 

Tj  :=  n/2 

if  <KE+n)<p  then  ^  :=  J^+n  fi 

repeat 
assert  |  J^— <J>(p  )  |  <e 
end 

that  results  is  more  similar  to  P2«  It  is  a  general-purpose  program  schema 
that  performs  a  binary-search  for  the  value  F,  of  an  invertible  monotonic  func- 
tion <t>  at  the  point  p  within  a  tolerance  e. 

We  show  now  how  this  binary-search  schema  may  be  applied  to  the  com- 
putation of  integer  square-roots.  Our  goal  is  to  construct  a  program  that 
sets  the  value  of  a  variable  z  to  L^nJ  ,  where  nelN  and  (_uj  is  the  largest 
integer  less  than  or  equal  to  u.   This  attempt  will  illustrate  some  of  the 
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difficulties  that  may  arise  in  trying  to  apply  a  schema. 

In  this  case,  we  cannot  directly  match  our  goal 

achieve  z=j_/nj  varying  z 

with  the  output  specification  of  the  schema 

assert  |e-<(>(p)  |<e. 

To  bring  out  the  analogy  we  must  first  expand  the  goal  z^L/nj  using  the 
definition  of  j_uj  ,  giving  the  equivalent  goal 

achieve  z</n,  /n<z+l,  zeZ. 

Since  we  know  that  the  schema  also  achieves  the  two  output  invariants 

assert  £<<K p),  <KpK5+e> 

we  can  compare  these  invariants  with  our  goal*   This  suggests  the  instantia- 
tion mapping 

S  -  z 
<t>  -*  /"" 

p  -*  n 

e  -►  1 

to  achieve  the  first  two  conjuncts  of  the  goal.   In  addition  we  will  have  to 
somehow  achieve  zeZ. 

The  preconditions  for  the  schema's  correctness  are 

assert  4>(u)<vEu<<t>(v) ,  o<<Kp)<i; 

instantiating  them  yields 
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4>(u)<vEu</v,  o</n<i . 

2 
Since  u  <v  is  equivalent  to  u</v  when  u>0,  the  first  condition  may  be  satis- 

2 
fied  by  taking  4>(u)  to  be  u  ,  provided  that  the  argument  u  is  never  negative. 

Noting  that  /n>0  suggests  letting  o=0;  /n<i  can  be  satisfied  by  letting  \=n+l. 

This  all  suggests  completing  the  instantiation  to  obtain 


% 

— ►   z 

4> 

-*  r 

P 

-*■  n 

<Ku) 

-*»   1 

2 

1    -♦   u 

0 

-►  0 

i    -*■   n+1. 

Applying  this  instantiation  to  the  schema,  we  obtain  the  program 

R2 :  begin 

comment   instantiated  schema 

assert  nelN 

(z,n)  :=  (0,n+l) 

loop  assert  z</n,  /n<z+n 

until  n<l 

n  :=  n/2 

2 
if  (z+n)  <n  then  z  :=  z+p  fi 

repeat 

assert  z</n,  /n<z+l 

end. 

It  is  easy  to  establish  that  both  n  and  z  are  nonnegative;  thus,  the  condi- 

2  .— 

tional  test  r\   <n  is  equivalent  to  n</n,  as  required. 

We  are  still  left  with  achieving  the  subgoal  zeZ.  One  way  that 
this  may  be  done  is  by  perturbing  the  final  value  of  z  just  enough  to  make  it 
an  Integer  while  preserving  the  two  relations  that  the  instantiated  schema 
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achieves.   Accordingly,  we  append  the  statement 

2 


if   n<([zj+l)    then  z  :»  |_ZJ 

else  z  :=  LZJ+1  fl 


Alternatively,  zeZ  could  be  achieved  by  ensuring  that  the  assignments  to  z 
preserve  that  relation.  This  avenue  is  pursued  in  Dershowitz  [1978]  ,  where  a 
series  of  additional  transformations  results  in  an  improved  version  of  integer 
square-root. 

Our  final  program  is 

R2 


begin 

comment   integer  square-root 

program 

assert  neIN 

(z,n) 

:=  (0,n+l) 

loop 

assert  z</n, 
until  n<l 

ti  :■  n/2 

,  /n<z+p 

if  (z+n)  <n 

then  z  :■ 

z+n  fl 

if 

repeat 

n<([zj+l)2 

then  z  :■ 
else  z  := 

|_zj+l  fi 

assert  z=(_/nj 

end. 
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Example  3_:  Associative  Recursion  S chema 

Abstraction  may  also  be  used  for  the  design  of  correctness- 
preserving  program  transformations.  For  example,  one  can  first  write  itera- 
tive versions  of  several  recursive  programs;  by  abstracting  those  programs,  a 
more  general  recursion-to-iteration  transformation  schema  can  be  obtained.  As 
we  shall  see  in  the  following  example,  very  little  information  is  gleaned  by  a 
comparison  of  output  specifications;  instead,  most  of  the  analogy  is  derived 
from  the  verification  conditions. 

The  two  given  programs  are 

P3 :  begin 

comment   factorial  program 

assert  nelN 

(z,y)  :=  (l,n) 

loop     assert   y!*z=n!,    yelN 

until   y=0 

(z,y)    :=   (yxz,y-l) 

repeat 
assert    z=n! 
end 


and 
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Q3 :  begin 

comment   summation  program 

assert  k,meZ,  k<m 

(s,j)  :=  (0,k) 

loop  assert  T™=  f(i)+s=Zm=kf(i),  jeZ 
until  j=m+l 
(s,j)  :=  (f(j)+s,j+l) 


repeat 

rl 
end. 


assert  s=s?=kf(i) 


Our  object  is  to  derive  a  schema  for  computing  recursive  functions  that  are 
like  factorial  and  summation. 

Matching  the  two  output  specifications 

assert  z=n! 

and 

assert  s=Zm  .  f(i) 
i=k 

suggests  as  one  possible  analogy 


n 

u!  <-►  Em  f(i). 
i=u 

The  two  output  variables  z  and  s  generalize  to  the  abstract  output  variable  C; 
the  input  variables  n  and  k  generalize  to  x»  the  two  functions  u!  and 
Z._  f(i)  generalize  to  an  abstract  function  variable  9(u). 

Applying  the  abstraction  mapping 
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z  -*   C 

n  -*  x 

u!  -►  9(u) 


to  P3  yields 


S3:  begin 

comment  abstracted  factorial  program 
suggest  yelN 
(C,y)  :=  (l,x) 

loop  suggest  e(y)xc=e(y),  yelN 
until  y=0 

(C,y)  :=  (y*C,y-l) 

repeat 
suggest  C=Q(x) 
end. 

Applying  the  mapping 

8  -►  C 

k  -  x 
^=uf(D  -  e(u) 

to  Q3  yields  a  schema  with  the  same  output  suggestion: 

T3 :  begin 

comment   abstracted  summation  program 

suggest  x.meZ,  x<m 

CC.j)  :-  (0,x) 

loop  suggest  G(j)+C»9(x),  jeZ 
until  j-m+l 
(C,j)  :-  (f(j)+C,j+l) 
repeat 

suggest  C"6(x) 

end . 
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Neither  abstract  program  is,  however,  correct. 

Both  programs  consist  of  a  single  loop;  their  respective  abstracted 
loop  invariants  are 

assert  0(y)xC=9(x)»  yelN 
and 

assert  G(j)+C=9(X),  jeZ- 
Matching  the  invariants  suggests  the  additional  aspect  of  the  analogy 

y  -*  V  «-  j 

X  -*•  •%   +—  + 

IN  -*  Q  «~  Z. 

Applying  the  corresponding  transformations  to  the  loop  invariants  we  obtain 
the  abstract  invariant 

assert  T(e(v),C)=6(x)>  veQ. 


Now,  we  must  consider  the  verification  conditions.   Applying  the 
transformations  to  the  initialization  condition  of  P3  we  get 

T(6(X),i)-e(x) 

on  the  other  hand,  applying  the  transformations  to  the  initialization  condi- 
tion of  Q3  gives 

t(0(x),O)=0(X) 
XeQ. 
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The   shared   condition 

xeQ 

becomes  a  precondition  for  the  schema.   To  unify  the  remaining  conditions  of 
the  two  programs  we  add  to  the  analogy 

1  -*•  a)  +-  0, 

to  obtain  the  abstract  condition 

T(e(x),w)-e<x), 

or  more  generally, 

t(u,go)=u. 
This  too  is  a  precondition. 

The  loop-exit  condition  derived  from  P3  is 

T(9(v),C)-e(X)  A  veQ  A  v=0  3  C=e(y); 
from  Q3 ,  we  get 

t(6(v),0-9(x)  A  veQ  A  v-nrfl  D  C-6(x). 
With  the  additional  abstraction 

0  -►  y  ♦-  mfl 
we  get 

T(e(v),C)-«(x)  A  veQ  A  v-y  D   C-9(x). 
For  simplicity,  we  shall  replace  this  condition  with  the  stronger 
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t(9(y),u)=»u. 

For  the  loop-body  paths,  we  have  the  conditions 
T(9(v),C)-e(x)  A  veQ  A  v*y  D   T(0(v-l),T(v,C))-e(x)  A  v-leQ 


and 


T(0(v),C)-e(X)  A  veQ  A  v*Y  D  x(0(v+l),T(f(v),C))-e(x)  A  v+leQ, 

for  P3  and  Q3,  respectively.  To  unify  v-l«— *v+l  and  v*—»-f(v),  we  need  the 
additional  abstractions 

u-1  -*  6(u)  <-   u+1 
v  -»■  a(v)  ■*—   f(v). 

(The  transformation  v— ►a(v)  applied  to  all  occurrences  of  v  in  P3  would  be 
overzealous;  it  should  be  localized  to  the  occurrence  that  led  to  the  differ- 
ence between  the  two  verification  conditions.  That  occurrence  is  in  the 
assignment  £:=t(v,£)  obtained  from  the  original  z.#siyxz.)  This  abstraction  map- 
ping yields 

x(e(v),C)-0(x)  A  veQ  A  v*Y  D   x(e(6(v)),T(<y(v),C))-e(x)  A  6(v)eQ, 

for  which  we  shall  use  the  two  preconditions 

v*Y  D   t(9(v),u)=t(9(6(v)),t(o-(v),u)) 
veQ  A  v#y  D   6(v)eQ. 


Finally,  the  verification  condition  for  the  termination  of  the 
abstracted  program  is 


(3uelN)6u(x)=Y- 
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This  too  becomes  a  precondition. 

The  complete  abstraction  is 


z  -+  C  ■*-"  s 

n  -►  x  +-  k 

u!    -  9(u)   4-  Sj.uf(l) 

y  -*•  v  4-  j 

X    — ►    t    «—    + 

IN  -►  Q  <—  Z 

1  -►  o)  ««-  0 

0  -+  y  «-  mfl 

u-1  -»•  6(u)   *-  u+1 

v  -*  a(v)  ♦—  f(v). 

Applying  these  abstraction  transformations  (in  order)  to  Q3 ,  and  collecting 
all  the  preconditions,  we  derive  the  schema 

S3:  begin 

comment   associative  recursion  schema 
assert  t(u,w)=u,  t(9(y),u)s»u, 

v*YZMQ(v),u)=T(e(6(v)),T(o(v),u)), 

XeQ,  veRAv*Y.D6(v)eQ, 

(3ue3N)6U(X)=Y 
(C,v)  :=  (w,x) 
loop  assert  x(9(v),C)*»9(x)  >  veQ 

until  v»y 

(C,v)  :-  (T(a(v),C),6(v)) 

repeat 
assert  C"9(x) 
end. 


In  this  manner  we  have  obtained  a  general  schema  for  computing  a 
function  9(x).  It  applies  to  recursive  functions  9(x)  such  that  9(y)™w  is  a 
unit  of  an  associative  and  commutative  function  x,  and  9(u)°t(9(6(u) ) ,o(u) ) 
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when  i#y  The  schema  is  similar  to  one  of  the  recursion-to-iteration 
transformations  of  Darlington  and  Burstall  [1978]. 

To  see  how  this  schema  may  be  applied  to  another  problem,  consider 
the  specifications 

R3 :  begin 

comment   list-reversal  program 

assert  lei 

achieve  z=reverse(J? )  varying  z 

end, 

where  L  is  a  set  of  lists  and  reverse(X)  is  the  list  containing  the  elements 
of  I  in  reverse  order.  Assume  that  we  are  also  given  two  relevant  facts  about 
reverse:  reverse( ())=■() ,  where  ()  is  the  empty  list,  and 
reverse(u)=rever8e(tail(u) )*(head(u) )  when  u*(),  where  u*v  concatenates  the 
two  lists  u  and  v,  (head(u))  is  a  one  element  list  containing  the  first  ele- 
ment of  u,  and  tail(u)  is  a  list  of  all  but  the  first  element. 

An  initial  comparison  of  the  schema's  output  specification  C=9(x) 
with  the  new  specification  z=reverse(A)  suggests  the  instantiation 

9  -+■  reverse 
C  -*•  z 
X  -  *• 

Instantiating  the  precondition 

v#Y  D   T(9(v),u)-T(e(6(v)),T(o(v),u)) 

gives 

v*Y  3  x(reverse(v)  ,u)s»T(reverse(6(v)),x(a(v)  ,u)  ). 

By  the  second  of  the  above  two  facts,  we  have  that  reverse(v)  may  be  replaced 
by  reverse(tail(v))*(head(v)),  provided  that  v  is  not  the  empty  list  ().   This 
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suggests  the  possibility  of  instantiating  y— ►  ()  to  obtain 

v*  ( )  D  t(reverse(  tail(  v)  )*(head(v)  )  ,u)=-t(reverse(6  (v)  )  ,t(o(v)  ,u)  )  . 

The  function  reverse  appears  on  the  two  sides  of  the  equality,  so  we  try  to 
generalize  this  condition  by  replacing  both  occurrences  of  reverse  with  an 
arbitrary  list  w.  (This  is  similar  to  the  generalization  technique  used  in 
the  theorem  prover  described  in  Boyer  and  Moore  [1980].)  To  do  that,  we  must 
first  unify  reverse(6(v))  with  reverse(tail(v) )  by  instantiating  6— »-tail.  We 
are  left  with 

v*()  D  x(w*(head(v)),u)=T(w,T(a(v) ,u)). 

Similarly,  we  unify  a(v)  with  (head(v)),  the  list  containing  just  the  first 
element  of  v,  obtaining 

v*()  Z)   x(w*v,u)=t(w,t(v,u)). 

This  matches  with  the  fact  that  *  is  associative,  i.e.  (w*v)*u=w*(v*u) ,  by 
instantiating  t-*-*. 

Applying  the  instantiations  that  we  have  found  to  the  other  five 
preconditions 

t(u,w)=u 
t(6(y),u)=u 

veQ  A  v*y  D   Mv)eQ 
(3ueIN)6U(x)=Y 

yields 
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U*0)=*U 

reverse( ())*u=u 

veQ  A  v*()  D  tail(v)eQ 
(3uelN)tailU(JD=(). 

But  reverse( ())=()  and  ()*u=u,  since  the  empty  list  ()  is  an  identity  element 
of  the  function  *.  Thus,  the  second  condition  holds.  The  first  suggests  let- 
ting ar-^O;  the  third  and  fourth  suggest  letting  Q-*L.  The  last  condition 
then  follows  from  the  third,  as  a  property  of  lists. 

The  completed  instantiation  is 

0  -*■  reverse 

C  -►  z 

X  -*  r 

Y  -►  () 

6  -►  tail 

a(u)  -»  (head(u)) 

T  -►  * 
(d  -  (). 

In  all,  we  have  derived  the  following  program 

R-3 :  begin 

comment   list  reversal  program 

assert  £eL 

(z,v)  :-  ((),*) 

loop  assert  reverse(v  )*z=»reverse(A) ,  veL 

until  v*() 

(z,v)  :=  ((head(v))*z,tail(v)) 

repeat 
assert  z=reverse(A) 
end. 
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In  this  example  most  of  the  instantiation  mapping  was  derived  from 
an  analysis  of  the  preconditions.  The  preconditions  served,  In  this  way,  to 
guide  the  construction  of  the  list-reversal  program  in  the  pattern  of  other 
recursive  functions. 
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III.  DISCUSSION 

We  have  presented  several  examples  demonstrating  a  methodology  for 
deriving  an  abstract  program  schema  that  captures  the  technique  underlying  a 
given  set  of  concrete  programs.  Once  derived,  the  schema  may  be  applied  to 
solve  new  problems  by  instantiating  the  abstract  entitites  of  the  schema  with 
concrete  elements  from  the  problem  domain.  We  have  also  seen  how  this  metho- 
dology can  be  used  to  derive  correctness-preserving  program  transformations 
and  to  guide  their  application. 

Abstraction  and  instantiation  complement  techniques  of  program 
transformation,  such  as  have  been  advocated  by  Knuth  [1974].  When  faced  with 
the  task  of  developing  a  new  program  (or  subprogram)  to  meet  a  set  of  specifi- 
cations, the  programmer  ought  to  first  search  for  an  applicable  schema.  After 
instantiating  the  schema,  transformations  may  be  applied  to  solve  any  remain- 
ing specifications  or  to  increase  efficiency.  If  no  applicable  schema  can  be 
found,  one  might  still  be  able  to  find  a  schema  or  program  solving  some  analo- 
gous problem,  and  modify  it  (see,  for  example,  Dershowitz  and  Manna  [1977]). 
The  two  programs  together  would  then  be  used  to  formulate  a  schema  for  future 
use. 

There  are  a  few  problems  inherent  in  the  use  of  analogies  for  pro- 
gram abstraction  and  instantiation.  These  include  "hidden"  analogies, 
"misleading"  analogies,  "incomplete"  analogies,  and  "overzealous"  analogies. 

Hidden  analogies  arise  when  given  specifications  (of  the  two  or  more 
existing  programs  in  the  case  of  abstraction,  and  of  the  abstract  schema  and 
concrete  problem  in  the  case  of  instantiation)  that  are  to  be  compared  with 
one  another  have  little  syntactically  in  common.  Since  the  pattern-matching 
ideas  that  we  have  employed  are  syntax  based,  when  the  specifications  are  not 
syntactically  similar,  the  underlying  analogy  would  be  hidden.  In  such  a 
situation  it  is  necessary  to  rephrase  the  specifications  in  some  equivalent 
manner  that  brings  their  similarity  out,  before  an  analogy  can  be  found.  This 
is  clearly  a  difficult  problem  in  its  own  right;  in  general  some  form  of 
means-end  analysis  seems  appropriate. 
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At  the  opposite  extreme,  a  syntactic  analogy  may  be  misleading.  The 
same  symbol  may  appear  in  the  specifications  of  two  programs,  yet  may  play 
nonanalogous  roles  in  the  two  programs.  Two  programs  might  even  have  the 
exact  same  specifications,  but  employ  totally  different  methods  of  solution. 
Situations  such  as  these  would  be  detected  in  the  course  of  analyzing  the 
correctness  conditions  for  the  abstracted  programs. 

We  have  seen  how  the  proof  of  correctness  of  a  program  can  be  used 

to  help  avoid  overzealously  applying  transformations  to  unrelated  parts  of  a 

program.   The  proof  also  helps  complete  an  analogy  between  two  programs,  only 
part  of  which  was  found  by  a  comparison  of  specifications. 

The  methods  we  have  described  appear  to  be  amenable  to  automation. 
The  necessary  reasoning  ability  is  the  same  as  is  needed  for  a  program- 
verification  system;  the  program  manipulation  abilities  are  similar  to  what  is 
required  of  program-transformation  systems.  Of  course,  we  do  not  expect  these 
methods  alone  to  suffice  for  an  automatic  program-abstraction  system  to  pro- 
duce and  apply  program  schemata.  But  we  can  envision  the  possibility  of  such 
methods  being  embedded  in  a  semi-automatic  program-development  environment  in 
which  the  system  performs  the  more  straightforward  steps,  and  the  human  pro- 
grammer guides  the  machine  in  the  more  creative  ones. 
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APPENDIX 

Gerhart  [1975]  recommended  the  hand-compilation  of  a  handbook  of 
program  schemata.  Such  a  collection  of  shemata,  together  with  a  library  of 
program  transformations,  could  be  used  in  an  interactive  program-development 
system.  In  this  appendix,  we  have  culled  fifteen  representative  schemata  from 
the  programming  literature. 


We  use  the  following  nomenclature: 

IN  set  of  natural  numbers 

3R  set  of  real  numbers 

Z  set  of  integers 

[u:v]  set  of  integers  between  u  and  v 

j,k,t  input  variable 

x  input  variable  or  vector  of  variables 

p,q  predicate  symbol 

c,d,e,f,g,h    function  symbol 

a,b  constant  symbol 

z,r  output  variable 

i,s,y,m  program  variable 

u,v,w  universally  quantified  variable  (quantifier  often  omitted) 

n  existentially  quantified  variable 

Each  of  the  following  schemata  is  followed  by  an  output  assertion  giving  its 

abstract  Input-output  specification.   They  are  preceded  by  an  input  assertion 

containing  the  preconditions  for  correct  application.   The  general  format  is 
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S  :  begin 

comment   title  (source) 

purpose 
assert   type  conditions, 

correctness  preconditions, 
termination  precondition 

•  •  • 

schema  body 

•  •  • 

assert   output  specification 
end. 

The  references  are  to  sources  that  present  an  abstract  schema;  they  are  some- 
what arbitrary,  as  the  methods  themselves  are  all  well  known.  (The  schemata 
may  differ  in  details  from  those  given  in  the  referenced  sources.) 


S i :    begin 

comment   element-by-element   (Gerhart    [1975]) 

achieve  q   for  all  integers   between  j  and  k 
assert   jeZ,  kelR,   bex, 

ue[j:k]Avex  2)  h(u,v)ex, 

ue[j:k]Avex  3  q(h(u,v),u), 

u,we[ j:k]AvexAu<wAq(v,u)    Z)  q(h(w,v),u) 
(z,i)    :=   (b,j) 
loop     assert   (Vue[  j:i-l]  )q(z  ,u)  ,    ie[  j:k+l]  Vi=j>k+1,    zex 

until   i>k 

(z,i)    :=   (h(i,z),i+l) 

repeat 
assert  (  Vue[  j:k]  )q(z  ,u)  ,  zex 
end 
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S  2 :  begin 

comment  extremum  (Dershowitz  and  Manna  [1975]) 

achieve  q  for  all  Integers  between  j  and  k 
assert  jeZ,  kelR, 

ue[j:k]  D  q(u,u), 

u,v,we[ j:k]Au<vAq(w,u)A~lq(w,v)    Z)  q(v,u) 
(z,i)    :=    (j,j) 
loop     assert   (Vue[  j:i]  )q(z  ,u)  ,    z,ie[  j:k]  Vi=j>k 

until  i>k-l 

i    :=   1+1 

if    ~|q(z,i)    then  z    :=   i   fi 

repeat 
assert   (Vue[  j:k]  )q(z  ,u)  ,    ze[j:k]Vj>k 
end 


S3 :  begin 

comment  linear-search  (Dijkstra  [1972]) 

find  least  integer  between  j  and  k  such  that  q  holds 
assert  jeZ ,  kelR 

z  :=  j 

loop  assert  ( Vue[  j:z-l]  )~lq(u)  ,  ze[  j:k+l]  Vz=j>k+1 

until  z>kVq(z) 

z  :=  z+1 

repeat 
assert  (3ne[ j:k] )q(n)  Z)   z=(min  ne[ j :k] )q(n) , 

z>j,  z>kVq(z) 
end 
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Si*:  begin 

comment  gradient-search  (Misra  [1978]) 

search  for  local  extremum 
assert  aex, 

uex  2)  t(u)  Lx, 
uex  3  q(u,u), 

u,v,wexAq(w,u)A~lq(w,v)  D  q(v,u), 
uLx  3  g(u)eu, 

u,v,wexAq(u,w)  3  q(u,v)Vq(v,w), 
(3nelN)|x|=n 
comment   |x|  denotes  the  number  of  elements  In  the  set  x 
z  :=  a 
loop  (m, s)  :=  (z,t(z)) 

loop  assert  ( Vuet(m)-s)q(z  ,u)  ,  z,mex,  sl_x 
until  s={} 
y  :■  g(s) 
s  :=  s-{y} 

if  ~" lq(z,y)  then  z  :■  y  fi 
repeat 
assert  (Vuet(m))q(z,u) ,  zex 
until  z=m 
repeat 
assert  (  Vuet(z) )q(z ,u) ,  zex 
end 
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S5 :  begin 

comment  binary-search  (Dershowitz  and  Manna  [1975]) 

approximate  transition  from  q  true  to  q  false 
assert  a,b,telR, 

q(a),  ~lq(b), 

q(u+t)At>v  D  q(u+v), 

t>0 
(z,y)  :=  (a,b-a) 
loop  assert  q(z),  ~lq(z+y),  a<z<z+y<bVa>b 

until  y<t 

y  :-  y/2 

if  q(z+y)  tben  z  :=  z+y  fi 

repeat 
assert  q(z),  ~|q(z+t),  a<z<b\/a>b 
end 
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Sg:  begin  proc  sort(x[j:k] ) 

comment  sorting  (Darlington  [1978]) 

sort  array  segment  x[j:k] 
assert  x[ j:k]ea[ j:k] , 

uea[u':w']  2)  f(u)ea[u" :w' ]*[u' :w'-l] , 
uea[u' :v' ]  Avea[v'+1:  w']  Z)   g(u,v)ea[u'  :w'] , 
uea[u':v']Avea[v'+l:w']  2)  bag(g(u,v))=bag(u)  Ubag(v)  , 
uea[u':w']Af(u)=(w,v)  3  bag(u)=bag(w) , 

uea[u'  :w']  Af  (u)  =  (w[u'  :w']  ,v)  Asorted(w[u'  :v]  )Asorted(w[v+l:w'  ]  )  2) 
sorted(g(w[u': v] ,w[v+l:w'])) 
comment  bag(u)=bag(v)  means  that  for  each  occurrence 

of  an  element  in  u  there  is  an  occurrence  of  the  element  in  v; 
sorted(w[u'  :w']  )  =  (  Vve[u'  :w'-l]  )w[v]  <w[v+l] ; 
a[u:v]  is  the  set  of  arrays  of  elements  of  a 
with  indices  in  [u:v]; 

x  denotes  the  value  of  x  upon  procedure  entry 
if  j<k  then  (x[j:k],m)  :»  f(x[j:k]) 
sort(x[ j:m] ) 
sort(x[m+l:k]) 

x[j:k]  :=  g(x[j:m],x[m+l:k])  fi 
assert  bag(x[ j:k] )=bag(x[ j:k] ),  sorted(x[ j:k] ) 
end 
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S7:  begin 

comment  associative-recursion  (Darlington  and  Burstall  [1976]) 

compute  f(x) 

assert  p(u)  3  f(u)=c(u), 

h(u,c(u))=u, 

~[p(u)  D  f(u)=h(f(e(u)),d(u)), 
h(u,h(v,w))=h(h(u,v),w), 
(3nelN)p(en(x)) 
if  p(x) 

then  z  :=  c(x) 

else  (z,y)  :=  (d(x),e(x)) 

loop  assert  h(f (y) ,z)=f (x) 
until  p(y) 

(z,y)  :=  (h(d(y),z),e(y)) 
repeat 
z  :=  h(c(y),z) 
fi 
assert  z=f(x) 
end 


S8:  begin 

comment  tall-recursion  (Wirth  [1976]) 

compute  f(x) 
assert  p(u)  2)  f(u)=c(u), 

~|p(u)  D  f(u)=f(e(u)), 

(3nelN)p(en(x)) 
y  :=  x 
loop   assert  f(y)=f(x) 

until  p(y) 

y  :■  e(y) 

repeat 
z  :=»  c(y) 
assert  z=f(x) 
end 
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S9 :  begin 

content  rlght-commutatlve-recurslon  (Cooper  [1966]) 
assert  p(u)  2)  f(u)=a, 

~lp(u)  D  f(u)=h(f(e(u)),d(u)), 

h(g(u,v),w)=g(h(u,w),v) , 

h(a,u)=g(a,u), 

(3ne]N)p(en(x)) 
(z,y)  :=  (a,x) 
loop  assert  u=(mln  nelN)p(e  (y)) 

D  f(x)-g(g(...g(g(2,d(y)),d(e(y) )),-.. ),d(eU_1(y))) 

until  p(y) 

(z,y)  :=  (g(z,d(y)),e(y)) 

repeat 
assert  z=f(x) 
end 


S10:  begin 

comment  Invert Ible-recurslon  (Cooper  [1966]) 

compute  f(x) 
assert  f(a)=c(a), 

u#a  D  f(u)-h(f(e(u)),u), 

e(g(u))=u, 

(3nelN)g  (a)=x 
(z,y)  :=  (c(a),a) 
loop  assert  z=f(y),  (3nelN)(y=g  (a)  A(Vue[0:n-l]  )g  (a)*x) 

until  y=x 

(z,y)  :=  (h(z,g(y)),g(y)) 

repeat 
assert  z=f(x) 
end 
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S i i :  begin 

comment  stack-Introduction  (Wossner,  et  al.  [1978]) 

compute  recursive  function  f(x)  using  stack 

assert  p(u)  2)  f(u)=c(u)> 

~lp(u)  D  f(u)=h(f(d(u)),u), 

(3nelN)p(dn(x)) 

comment  s  is  the  list  (s  ,s   ,,,,,,s, ); 

n  n-1      1 

head(s)=s  ;  tail(s)=(s   ..•••,81); 
n  n-1      1 

uos=(u>sn,-«-,s1) 
(y,s)  :=  (x,()) 
loop  assert  f  (x)=h(-  •  -h(h(f  (y)  ,sn)  »3   j^)  •  •  •  .s^ 

until  p(y) 

(y,s)  :=  (d(y),yos) 

repeat 
z  :=  c(y) 

loop  assert  f(x)=h( ♦ • «h(h(z ,s  ),s  , )»««,s, ) 

n   n— l      l 

until  s=() 

(z,s)  :=  (h(z,head(s)),tail(s)) 

repeat 
assert  z=f(x) 
end 
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»12:  begin 

coament  double-recursion  (Knuth  [1974]) 

compute  f(x) 
assert  p(u)  Z)   f(u)=c(u), 

lp(u)  ^  f(u)-h(f(e(u)),f(d(u))), 
h(a,u)=u, 

h(u,h(v,w))=h(h(u,v),w), 
p(x)V(3nem)gn(x)  =  {}, 

where  g(u)={e(v)  IveuAlp(v)}  U{d(v)  IveuAlp(v)} 


come 

nt   s  Is  the 

head(s)=s  ; 
n 

list  \ 
tail(s 

n  n— 1 
')=(sn_r-. 

•,s1); 

-,8^5 

(z,s) 

uos=(u,s  , • 
n 

:-  (a,(x)) 

",8^ 

loop 

assert  f(x): 

»h(z,h( 

;s1,h(s2>h( 

•"'h(Vr 

V 

until  s=() 

(y,s)  :=  (head(s), 

tail(s)) 

if   p(y) 

then 

z  :=  h(z,c 

(y)) 

else 

s  :■  e(y)c 

d(y)os 

fl 

repeat 

assert  z=f(x) 

end 

)))) 
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s13:  begin  proc  back(t,x,z) 

consent  backtracking  (Gerhart  and  Yelowitz  [1976]) 

collect  all  vectors  beginning  with  x  satisfying  p 
assert  xea,  2Q, 

uea  3  t(u)  La, 

uLa  2)  g(u)eu, 

(3nelN)|t*({x})|=n 

comment   t*(u)=u|_ft (u)  Ut~2(u)  U-  •  •  , 

where  T(u)  =  U   t(v); 
veu 

I*  * 

t  (u) I  denotes  the  number  of  elements  in  the  set  t  (u); 

z  denotes  the  value  of  z  upon  procedure  entry 
if  p(x)  then  z  :=  zU{x}  fi 
y  :=  t(x) 

loop  assert  zU{uet  (x)|p(u)} 
=zU{uet*(y)|p(u)} 

until  y={ } 

m  :=  g(y) 

y  :=  y-{m} 

back(t ,m,z) 

repeat 
assert  z=z|_l{uet  (x)|p(u)} 
end 
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<m'.    begin 

comment  marking  (Yelowitz  and  Duncan  [1977]) 

collect  elements  related  by  t  to  x 
assert  xCa,  tIZa  , 

{n|  (u,n)Ew}  Cf(u,v,w)  Cv, 

uCa  2)  g(u)eu, 

(3nelN)|t*(x)|-n 

comment   t  (x)ax|Jt(x)  Lit  (x)  [_]•••, 

where  t"(x)=»U   {n|(u,n)et}; 
uex 

t  (x) I  denotes  the  number  of  elements  in  the  set  t  (x) 
(z,s,y)  :=  (x,x,t) 
loop  assert  sCzlZt  (x)  Cz Uy  (s)Ca,  yCt 

until  y-OVs-0 

m  :=  g(s) 

s  :=  sUf(m,z,y)-{m} 

z  :=  zU{u|  (m,u)ey) 

y  :»  y-{(u,v) |(m,v)ey} 

repeat 
assert  z=t  (x) 
end 
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S15:  begin 

comment  additive-relation  (Dershowitz  and  Manna  [1981]) 

achieve  p(z)  maintaining  relation  between  r  and  z 
assert  g(u,v)=g(v,u) , 

g(g(u,v),w)=g(u,g(v,w)), 

h(h(u,v) ,w)=h(h(u,w) ,v) , 

b(g(u,v),w)=g(h(u,w),h(v,w)), 

(3nelN)p(dn(x)),  where  d(u)=g(u,h(f (u) ,a) ) 
(z,r)  :=  (x,t) 
loop  assert  g(h(x,b) ,h(r,a) )=g(h(t,a) ,h(z  ,b) ) 

until  p(z) 

(z,r)  :=  (g(z,h(f(z),a)),g(r,h(f(z),b))) 

repeat 
assert  p(z),  g(h(x,b) ,h(r,a) )=g(h(t,a) ,h(z,b) ) 
end 
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